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(S) System and method for enabling before/after method processing in an object oriented system. 



(57) A system for creating before and after be- 
haviour upon invocation of a method in an 
object-oriented system. The framework pro- 
vides metadasses classes containing methods 
for dispatching a before method and an after 
method at the time of invocation of each client 
method in subclass instances. Object-oriented 
system properties of inheritance and encapsu- 
lation are supported as are derived metadas- 
ses. Derivation ensures that the specification 
syntax for each class does not impact the 
expected result The combination of explicit 
before after d asses, dispatcher dass, and de- 
rived metadasses ensures that the system will 
have associative composition. 
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The present invention relates to electronic data 
processing systems and more particularly to systems 
in which processing methods and data are gathered 
into objects. Still more particularly, the present inven- 
tion relates to object-oriented systems in which spe- 
cial methods may be processed before and after de- 
fined processing methods. 

The development of application and system soft- 
ware for data processing systems has traditionally 
been a time consuming task. The field of software en- 
gineering has attempted to overcome the limitations 
of traditional techniques by proposing new, more ef- 
ficient software development models. Object-orient- 
ed programming has emerged as a promising technol- 
ogy that will allow rapid development, implementa- 
tion, and customization of new software systems. 

Progress in programming technology can be 
viewed as being shown by the increased level of ab- 
straction employed. Programming technology has 
progressed through abstractions that grouped ever 
larger entities. Assembly language instructions were 
first gathered into control structures, and control 
structures latter gathered in to procedures. Proce- 
dures, in turn, were gathered into abstract data types. 
Object-oriented programming can be viewed as pro- 
viding a higher level of abstraction of programming 
entities than these previous techniques. Object-ori- 
ented programming gathers abstract data types into 
an inheritance hierarchy. The present invention is di- 
rected to a further abstraction, a metaclass that pro- 
vides before and after processing for methods of in- 
stances of its instances. 

Object-oriented programming uses a toolkit of 
system objects that can be assembled to perform the 
required task. Each object has certain data attributes 
and processes or methods that operate on that data. 
Data is said to be "encapsulated" by an object and can 
only be modified by the object methods. Methods are 
invoked by sending a message to an object identify- 
ing the method and supplying any needed arguments. 

Object-oriented systems have two important 
properties in addition to encapsulation. Firstly, "inher- 
itance" which is the ability to derive a new object from 
an existing object and to inherit all properties, includ- 
ing methods and data structure, from the existing ob- 
ject The new object may have certain unique features 
that are supplied as overrides or modifications to the 
existing class. For example, a new subclass needs to 
specify only the functions and data that distinguish 
that class from the existing more general class. Sec- 
ondly, "polymorphism" which is the ability of an entity 
(e.g. a variable) to refer at run-time to instances of dif- 
ferent classes. Practically, this means that a single 
message to an object can be processed in different 
ways depending on the object itself. 

Inheritance and polymorphism create a powerful 
structure for implementing new software systems. 
The software developer does not have to develop 



each piece of a system, he or she need only specify 
the unique features of the system. 

The power of object-oriented systems is realized 
through the development of system "frameworks." A 

5 framework is a collection of base classes that can be 
used by a system implementor to create a final sys- 
tems product. The framework is defined and devel- 
oped to work together as a system. Conceptually, the 
framework is much like a set of standard hardware 

10 components used by computer hardware builders. 
Each of the components has certain defined func- 
tions and interfaces and the engineer assembles 
these components according to a particular design to 
create a unique hardware system. Object frame- 

15 works, like electronic components, typically cannot 
be changed by the engineer. Instead the engineer 
must add other objects that interface with the frame- 
work in the manner defined by the framework. 

Examples of object frameworks are contained in 

20 the SOMobjects product developed by the IBM Corp. 
SOMobjects defines a number of objects, object 
classes, and object metaclasses for use in software 
system development. The system developer uses 
components of the SOMobjects framework and ex- 

25 tends those by creating new subclasses based on the 
framework classes. SOMobjects provides a compiler 
language neutral interface description language 
(IDL) for specifying new subclasses and methods. 
The IDL specification created by the software engi- 

30 neer contains information about the parent classes 
used by the engineer and specifies any methods that 
override methods in parent classes. 

Computer software developers frequently need 
to know the state of a computer system before exe- 

35 cution of a process and then again after execution of 
that process. This information can be used when de- 
bugging a new system to make sure the process is 
performing correctly. It can also be used to implement 
features such as security locks, record locks, and da- 

40 tabase logging. Existing object-oriented systems do 
not provide an easy way to specify methods to be 
executed before and after each instance method with- 
out explicitly specifying the behaviour for each in- 
stance method. 

45 The technical problem addressed by the present 

invention is how to provide an object based ability to 
specify methods to be performed before and after the 
methods of all instances of a particular class and en- 
sure that these methods compose. 

so Accordingly, the present invention provides a 

system for enabling construction of object-oriented 
classes implementing before and after behaviour for 
each dispatch of a method process, said system op- 
erating in a computer system having memory means 

55 and processing means said system including at least 
one class means having data and methods for proc- 
essing said data, the system comprising: means for 
dispatching a BeforeMethod and an AfterMethod re- 
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spectively before and after dispatching a method 
process, said means for dispatching being responsive 
to signalling of a class means; class means for signal- 
ling method processing dispatch, said means being 
responsive to before and after behaviour requests, 5 
said class means being a subclass of one of said at 
least one dass means and an instance of said means 
for dispatching; and subclass means for generating 
before and after behaviour requests to said class 
means, said subclass means being a subclass of said 10 
class means and being responsive to an instance 
method invocation. 

An embodiment of the invention provides a meth- 
od for generating associative object metadass com- 
positions in a computer system having memory and 15 
at least one central processing unit and, the method 
comprising the steps of: specifying a plurality of 
classes having data and methods for operating on 
said data; creating a modifiable metaclass for dis- 
patching for execution before or after method invoca- 20 
tionsLtesting said plurality of classes and said modi- 
fiable metaclass to determine a set of methods re- 
quired for consistency; and creating a metaclass hi- 
erarchy based on said testing. 

Af urther embodiment of the invention provides a 25 
system enabling special method processing before 
and after processing of a method defined for an object 
in an object-oriented computer system, each object 
having one or more object classes and each of said 
one or more object classes having one or more object 30 
metaclasses, the special method processing enabled 
in an object-oriented framework having unmodif iable 
and modifiable classes, the system comprising: stor- 
age means for storing said objects, classes and met- 
aclasses; dispatch means for dispatching said meth- 35 
ods and said special methods, said dispatch means 
being a modifiable metaclass in said object-oriented 
framework. 

The present invention solves the before and after 
method execution problem by providing an object-ori- 40 
ented framework that has a BeforeAf terDispatch met- 
aclass as the class for a BeforeAf ter class. Classes 
having before/after behaviours can be created as 
subclasses of the BeforeAf ter class. The BeforeAf ter- 
Dispatch metaclass supports the dispatch methods 45 
necessary to implement before/after processing and 
is structured to ensure associative composition of 
subclass descriptions. 

An embodiment of the present invention is direct- 
ed to a system for enabling construction of object-ori- so 
ented classes implementing before and after behav- 
iour for each dispatch of a method process, the sys- 
tem operating in a computer system having memory 
means and processing means, the system including 
at least one class means having data and methods for 55 
processing the data. The system has the following 
components: means for dispatching a BeforeMethod 
and an Af terMethod respectively before and after dis- 



patching a method process, the means for dispatch- 
ing being responsive to signalling of a class means; 
class means for signalling method processing dis- 
patch, the means being responsive to before and af- 
ter behaviour requests, the class means being a sub- 
. class of one of the at least one class means and an 
instance of the means for dispatching; and subclass 
means for generating before and after behaviour re- 
quests to the class means, the subclass means being 
a subclass of the BeforeAfter Class and being re- 
sponsive to an instance method invocation. 

The invention advantageously enables before/af- 
ter processing for all methods of a particular class. 

Preferably, an embodiment of the invention fur- 
ther advantageously implements a before/after proc- 
essing structure that consistently composes at run 
time. 

Preferably, the invention provides a before/after 
structure that is associative, i.e. composition of three 
or more beforeAfter metaclasses produces the same 
result regardless of the order in which they are com- 
posed, e.g., ensuring that (A+B)+C = A+(B+C). 

An embodiment of the present invention will now 
be described, by way of examply only, with reference 
to the accompanying drawings in which: 

figure 1 is a block diagram of a computer system 
of the type to embody the present invention; 
figure 2 is a diagram illustrating a basic System 
Object Model framework and labelling the frame- 
work elements; 

figure 3 is an object diagram illustrating the pre- 
ferred embodiment of the present invention; 
figure 4 is an object diagram illustrating an appli- 
cation of the framework of the preferred embodi- 
ment. 

Figure 1 illustrates a computer system capable of 
being structured according to the present invention. 
The computer system 1 00 has.a processor 1 01 , a ran- 
dom access memory 104, a permanent storage de- 
vice 102, a communications adapter 106 connecting 
the system to a network 1 08, and an I/O controller 110 
controlling the operation of a display 112, a keyboard 
114, and a pointing device 116. The computer system 
can be one of many known systems such as the IBM 
Personal System/2 (PS/2) computer system or the 
IBM RISC System/6000 computer system. (IBM, Per- 
sonal System/2, PS/2, and RISC System/6000 are 
trademarks of the IBM Corp.) The components can 
be of any known type. Permanent storage device 104 
can be a fixed disk storage system, a removable disk- 
ette, or other fixed or removable media such as tape 
cartridge, CD-ROM, or WORM. The framework of the 
present invention may be embodied in a removable 
media for storage and distribution. 

The terminology of the IBM System Object Model 
object framework is presented with reference to Fig- 
ure 2. The IBM System Object Model product SOM ob- 
jects is an object-oriented framework. The framework 
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consists of classes and objects that belong to those 
classes. In SOMobjects, classes are themselves ob- 
jects and have all the properties of an object Classes 
have the additional property of containing information 
about the methods or behaviours to which each object 
of the class responds. An object responds to a method 
if the object contains code for that method. A class is 
said to support a method when objects of that class 
respond to that method. Methods supported by a 
class are those explicitly defined for that class and 
those inherited from classes that are parent classes 
for that class. Objects respond only to those methods 
supported by their class. The class of a class is 
termed a meta-class. 

SOMobjects has as its root object SOMObject 
202. The class of SOMObject is SOMCIass 204. A 
system developer can use SOMobjects to add addi- 
tional classes. For example, the class "Dog" 206 is a 
subclass of SOMObject 202. "Rover 11 207 is an in- 
stance of "Dog". Two relationships between objects 
can be expressed. The "instance of 1 relation is shown 
in the figure by a dashed arrow, e.g. 208 from an ob- 
ject to its class. The inverse relation is "class or, i.e., 
Dog is an "instance or SOMCIass and SOMCIass is 
the "class or Dog. The second relationship is "sub- 
class of 1 represented by solid lines, e.g. 210, and its 
inverse "parent of. Thus Dog is a "subclass or SO- 
MObject and SOMObject is the "parent of Dog. Sub- 
classes inherit methods from parent classes and can 
define additional methods that refine the implemen- 
tation. 

SOMCIass is identified in Figure 2 as being in the 
set of metaclasses. This is because it is the "class or 
a class. Additional metaclasses, classes and objects 
can be created using known object-oriented techni- 
ques. 

The preferred embodiment of the present inven- 
tion is shown in Figure 3. The framework of Figure 2 
has been extended by adding four new metaclasses. 
SOMMBeforeAfterDispatcher 220 is a subclass of 
and an instance of SOMCIass 204. SOMMParentBe- 
foreAfter 222 is a subclass of SOMCIass 204 and an 
instance of SOMMBeforeAfterDispatcher 220. 
SOMMBeforeAfter 224 is a subclass of SOMMPar- 
entBeforeAfter and an instance of SOMMBeforeAf- 
terDispatcher 220. Finally, SOMMTraced 226 is a 
subclass of SOMMBeforeAfter 224 and an instance of 
SOMMBeforeAfterDispatcher 220. 

SOMMBeforeAfterDispatcher 220 is the key 
component of the new framework. This is a class of 
several" metaclasses (and thus a meta-metaciass) 
and provides BeforeAfter behaviours to its instance 
metaclasses, e.g., SOMBeforeAfter 224. Any sub- 
class of SOMMBeforeAfter 224 or the other meta- 
classes will also have the ability to cause execution 
of a method before each instance method execution 
and after each instance method execution by speci- 
fying a BeforeMethod or an Af terMethod or both. The 



abstraction of BeforeAfter processing into a meta- 
metaclass allows behaviour implementation without 
specification in the Interface Definition Language 
(IDL) that is used to describe objects and their inter- 
5 relationships. 

Procedurally, implementation of before/after 
processing requires that the BeforeMethod be dis- 
patched for execution, the instance method be dis- 
patched for execution, then the AfterMethod be dis- 
w patched for execution. This procedure can be embod- 
ied in Dispatcher methods to handle dispatching of 
methods for execution. Because SOMMBeforeAfter 
224 and its subclasses must respond to this method, 
it must be supported by the class of SOMMBefore- 
15 After, i.e. metaciass SOMMBeforeAfterDispatcher 
220. In particular, the SOMMBeforeAfterDispatcher 
implements BeforeMethodDispatch that searches for 
and dispatches any BeforeMethod in the class or par- 
ent classes, and AfterMethodDispatch that searches 
20 for and dispatches any AfterMethod in the class or 
parent classes. 

The above structure provides a framework that 
allows a software developer to create a before/after 
class by creating a subclass of SOMMBeforeAfter 
25 and by defining a BeforeMethod and an AfterMethod. 

SOMMTraced 226 is an example of a before/after 
class supplied with the SOMobjects framework. 
SOMMTraced provides the methods to support trac- 
ing of method execution in an object-oriented system. 
30 For example, it provides a BeforeMethod to print the 
calling parameters to a method call and an AfterMe- 
thod to print the return value from that method call. 

SOMMParentBeforeAfter 222 is provided for 
those situations where before/after processing is de- 
35 sired only for inherited methods. 

The structure of the preferred embodiment meta- 
metaclass SOMBeforeAfterDipatch is important be- 
cause it provides associative composition of meta- 
classes for an object-oriented system. SOMobjects 
40 provides a syntax for specifying relationships be- 
tween objects. This language allows the developer to 
provide, for example, an explicitly def ined metaciass 
for each defined class. A complex system may be val- 
idly expressed in several different ways. Consistent 
45 operation of the system requires that each of those 
valid expressions provide the same result when proc- 
essed. . . 

SOMobjects enforces consistency by denving t 
metaclasses for each object The process for deriving 
so metaclasses is discussed in U.S. Patent Application 
Serial Number 08/042,930 filed April 5, 1993. 

SOMobjects allows multiple inheritance, i.e., a 
class can be a subclass or instance of two or more 
classes. Derived metaclasses ensures that each in- 
55 stance of that class validly responds to inherited 
methods. SOMobjects checks at runtime to deter- 
mine whether the metaciass for each class supports 
the methods that could be executed by instances of 
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that class. If not, SOMobjects derives the metaclass 
necessary to support all required methods. 

The SOMMBeforeAfter and SOMMBeforeAfter- 
Dispatcher structure supports metaclass derivation. 
An example of this is shown in Figure 4. A "Dog" class 5 
231 can be created as a subclass of SOMObject to de- 
fine the properties of a class of Dogs. Dog may in- 
clude a method "Fetch" that causes an animated im- 
age of a dog to cross the display screen 112. "RinTin- 
Tin" 233 can be created as an instance of "Dog" hav- 10 
ing certain properties. Sending the message "Fetch" 
to "RinTinTin" would cause an animated dog to cross 
the display screen. 

The developer may want to add before/after fea- 
tures to the class of Dog. This can be done by creating 15 
"Barking" 232 a subclass of SOMMBeforeAfter. 
"Barking" can include a Before Method that causes 
the word "WOOF" to be printed, and an AfterMethod 
that causes the word "woof to be printed. The class 
"BarkingDog" 234 is created as a subclass of Dog 231 20 
having an explicit metaclass of Barking 232. An in- 
stance of BarkingDog, e.g., Lassie, 236 would re- 
spond to the message "Fetch" by causing the printing 
of "WOOF", the animated crossing of the screen by a 
dog, and the printing of "woof. 25 

A fierce dog could be created in a similar way by 
specifying subclassing SOMMBeforeAfter to create a 
"Fierce" class 230. The FierceDog would say "GRRR" 
before acting and "grrr" afterwards. 

The composition problem is noticed when the de- 30 
veloper attempts to create a "FierceBarkingDog". 
This new class can be defined in at least three ways. 
First, the class could be defined as a subclass of Dog 
with an explicit metaclass of "FierceBarking". "Fierce- 
Barking" would be created by multiple inheritance 35 
from Fierce and Barking. Second, the class could be 
defined as a subclass of FierceDog and BarkingDog. 
Finally, the class could be defined as a subclass of 
BarkingDog with an explicit metaclass of Fierce. Each 
of these represent valid SOMObject expressions. It is 40 
essential that each produces the same result. 

SOMObject metaclass processing will analyze 
the methods required to be supported and derive any 
necessary metaclass. The result will be a use of met- 
aclass FierceBarking as the actual metaclass for 45 
each of the three defined Fierce BarkingDogs defined 
above. The explicit metaclass definition would be 
overridden to ensure consistency. A "Rover" instance 
of FierceBarkingDog would respond "GRRRWOOF" 
(animated dog) "woofgrrr" regardless of which of the so 
three classes it instantiates. The result is associative 
composition because the form of definition is imma- 
terial. Note, however, that the composition is not com- 
mutative, i.e., a FierceBarkingDog is not the same as 
a BarkingFierceDog. 55 

The code for implementing the preferred embodi- 
ment of somDispatch in a before/after environment is 
illustrated below. This code is illustrative only and it 



will be clear to others in the field that many alternative 
embodiments exists without departing from the spirit 
of the invention. 

The basic dispatch routine can be implemented 
as follows. "Self refers to the instance receiving the 
message. "clientMethod" is the identifier of the meth- 
od being invoked by the application and acquiring be- 
fore/after behaviour. 
somDispatch(self, clientMethod) 

BeforeMethodDispatch(class(class(self)) t 
self, ...); 

retval := clientMethod(self, ...); 

AfterMethodDispatch(class(class(self)), 
self,...); 

return retval; 

The Before Method Dispatch is implemented as fol- 
lows: 

BeforeMethodDispatch(aMetaclass, clientOb- 
ject, ...) 

if aMetaclass defines BeforeMethod 
BeforeMethod(clientObject) 

else 

for all parents of aMetaclass that 
support BeforeMethod 

BeforeMethodDispatch( 

aParent, clientObject, ...) 

This method will cause a BeforeMethod to be execut- 
ed if defined for the client object or will cause a hier- 
archy traversal towards SOMCIass looking for the 
first metaclass that defines BeforeMethod. 
AfterMethodDispatch is implemented as follows: 

AfterMethodDispatch(aMetaclass, clientOb- 
ject, ...) 

if aMetaclass defines AfterMethod 
AfterMethod (clientObject, ...) 

else 

for all parents of aMetaclass that 
support AfterMethod(in reverse order) 

AfterMethodDispatch(aParent, 

clientObject, ...) 

AfterMethodDispatch traverses the hierarchy in re- 
verse order where an AfterMethod is not defined for 
the client object. 



Claims 

1. A system for enabling construction of object-ori- 
ented classes implementing before and after be- 
haviour for each dispatch of a method process, 
said system operating in a computer system hav- 
ing memory means and processing means (101) 
said system including at least one class means 
having data and methods for processing said 
data, the system comprising: 

means (220) for dispatching a BeforeMe- 
thod and an AfterMethod respectively before and 
after dispatching a method process, said means 
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for dispatching being responsive to signalling of 
a class means; 

class means (224) for signalling method 
processing dispatch, said means being respon- 
sive to before and after behaviour requests, said 5 
class means being a subclass of one of said at 
least one class means and an instance of said 
means for dispatching; and 

subclass means (230) for generating be- 
fore and after behaviour requests to said class 10 
means, said subclass means being a subclass of 
said class means (224) and being responsive to 
an instance method invocation. 

2. A method for generating associative object met- 15 
aclass compositions in a computer system having 
memory (104) and at least one central process- 
ing unit (101) and, the method comprising the 
steps of: 

specifying a plurality of classes (202, 20 
231 ,234) having data and methods for operating 
on said data; 

creating a modifiable metaclass for dis- 
patching for execution before or after method in- 
vocations; 25 

testing said plurality of classes (202, 
231 ,234) and said modifiable metaclass to deter- 
mine a set of methods required for consistency; 
and 

creating a metaclass hierarchy (232,224, 30 
222) based on said testing. 

3. Asystem enabling special method processing be- 
fore and after processing of a method def ined for 

an object (236) in an object-oriented computer 35 
system, each object having one or more object 
classes (224) and each of said one or more object 
classes having one or more object metaclasses 
(232), the special method processing enabled in 
an object-oriented framework having unmodifi- 40 
able and modif iable classes, the system compris- 
ing: 

storage means (104) for storing said ob- 
jects, classes and metaclasses; 

dispatch means (220) for dispatching said 45 
methods and said special methods, said dispatch 
means being a modifiable metaclass in said ob- 
ject-oriented framework. 
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